Чем штатный sail не угодил?

Задача докера обеспечить полностью идентичное окружение на локальной и прод среде, включая все настройки (кроме специальных дев.), все расширения и их версии, все зависимости и их оркестрацию. Помимо этого, ещё обеспечить билд конейнера (например через мультистейдж) в регистри для дальнейшего деплоя.

А Sail - инструмент, аналогичный Open Server, он подходит исключительно для начинающих/джунов, просто чтобы запустить и всё хоть как-то работало, при этом не обеспечивает ничего из перечисленных задач. А докер там исключительно как платформа на которой он запускается. С таким же успехом можно пользоваться тем же Denwer или Open Server, теряется весь смысл докера.

Смысла добавлять поддержку того, что априори не совместимо с продом - нет (например, на проде caddy).

Задача докера обеспечить полностью идентичное окружение на локальной и прод среде, включая все настройки (кроме специальных дев.), все расширения и их версии, все зависимости и их оркестрацию. Помимо этого, ещё обеспечить билд конейнера (например через мультистейдж) в регистри для дальнейшего деплоя.

Согласен, но не со всем. Докер хоть и позволяет воспроизвести production окружение, но нет смысла делать это для local dev окружения всегда и на 100%.

Например, для отладки и профилирования может потребоваться задействовать xdebug, которого на проде быть по хорошему не должно. Также и настройки opcache могут отличаться от production.

Для проверки рассылки используют mailhog контейнер, который тоже нужен только для local dev.

Если необходимо приблизить dev local окружение к production, то я бы рекомендовал сделать сначала docker-compose.yml и Dockerfile для сборки и поднятия production контейнера, а потом уже в docker-compose.override.yml добавить то, что нужно для локальной разработки.

Например, я бы не рекомендовал монтировать локальную директорию .:/home/laravel/laravel.su на проде, потому-что там в принципе не должно быть исходников.

Также если потребуется внести особые изменения в образ для local dev, то тут можно будет использовать мультистейдж, про который ты упомянул.

В production окружении docker compose при запуске игнорирует docker-compose.override.yml, но стоит проверить лишний раз.

Например, для отладки и профилирования может потребоваться задействовать xdebug, которого на проде быть по хорошему не должно. Также и настройки opcache могут отличаться от production.

Я об этом явно написал:

включая все настройки (кроме специальных дев.)

Как и про мультистейдж билд, где локальное можно поверх отдельным слоём накатить.

Для проверки рассылки используют mailhog контейнер, который тоже нужен только для local dev.

Это всё решается докер профилями или как ты правильно написал через .override.yml

Например, я бы не рекомендовал монтировать локальную директорию .:/home/laravel/laravel.su на проде, потому-что там в принципе не должно быть исходников.

Ну если деплоить контейнер на прод через сварм или кубер, то очевидно для этого делается COPY в докерфайле. Но в данном случае пока что об этом речи не идёт. Сейчас хотя бы локально поднять всё с таким же окружением, т.к. сейчас работать с проектом нельзя, т.к. докер тупо отсутствует.

P.S. Понимаю, что для "просто поднять хотя бы" ты прав и Sail достаточно, но как бы от него потом и так и так придётся избавляться в пользу более адекватного и prod-like окружения.